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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 
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Scope 



The present document describes the signalling behaviour of the transport functions BTF & RCEF for the listed multicast 
transport control protocols (IGMP, MLD), and provides a mapping between these transport control protocols and 
TISPAN RACS Re interface as specified in TS 183 060 Release 2 [1]. 

2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 183 060 (V2.1.1): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); Resource and Admission Control Subsystem (RACS); Re 
interface based on the DIAMETER protocol". 

[2] IETF RFC 3376: "Internet Group Management Protocol, Version 3". 

[3] IETF RFC 2236: "Internet Group Management Protocol, Version 2". 

[4] IETF RFC 3810: "Multicast Listener Discovery Version 2 (MLDv2) for IPv6". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

Not applicable. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

termination point: element acting as the neighbouring multicast router receiving and handling 1GMP/MLD request 
from the UE 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

A-RACF Access-Resource and Admission Control Function 

BTF Basic Transport Functions 

CAC Connection Admission Control 

IGMP Internet Group Management Protocol 

IPTV Internet Protocol Television 

MLD Multicast Listener Discovery 

RACS Resource and Admission Control Subsystem 

RCEF Resource Control Enforcement Function 

UE User Equipment 



4 Overview 

4.1 Overview of multicast transport control protocol to Re 
mapping 

PULL mode for multicast applies in two cases: 

• PULL mode case 1: When it applies below the termination point in the access segment, the PULL mode is 
used to request resources for a channel in the access network and/or to indicate that the resources associated to 
a channel can be released as the channel is left. This is per user and can be combined with the PUSH mode at 
session initiation to allow the A-RACF to download the permitted multicast flow for that user to the RCEF. 

• PULL mode case 2: When it applies beyond the termination point, the PULL mode is used to request shared 
resources to transport a multicast flow corresponding to a channel that has been requested by one or more 
users. 

Figure 4. 1 shows a generic scenario for both cases of PULL mode. Transport processing nodes comprises one or several 
BTFs and one or several RCEFs that may be co localized. 
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Figure 4.1 : A generic scenario for both cases of PULL mode 

1) Upon session activation, the RACS downloads the policy rules in the RCEF in charge of enforcing policies 
applicable to the access segment. This corresponds e.g. to the list of subscribed channels in case of IPTV 
service activation. For each policy, bandwidth is set to zero, this will force the transport processing node to 
trigger the PULL mode. 

2) The BTF receives a multicast request. This message may contain IGMP/MLD "leave" and/or "join" requests. 

3) The BTF requests CAC towards the RCEF. The RCEF checks that the requested channel corresponds to an 
existing policy-rule. If not, it ignores the request and the user will not receive the channel. If a policy-rule 
exists, and if PULL mode applies below the termination point, the RCEF sends a CC-Request to the RACS 
based on parameters received in the multicast request. It has therefore to indicate to the RACS that the UE 
wants to leave a particular channel and/or wants to join another one. If enough resource is available to join the 
requested channel, the RACS answers positively to the RCEF. 

4) If the step 3 is successful, the BTF forwards the request to the RCEF dealing with resource beyond the 
termination point. If PULL mode applies beyond the termination point, the RCEF sends a CC-Request to the 
RACS based on parameters received in the multicast request. It does not have to check any policy-rule 
previously downloaded because this request is not linked to any user's rights. The RACS can determine if 
enough resource is available in the aggregation segment. If this is the case, the RACS answers positively to the 
RCEF. 
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5 Behaviours of the transport functions for multicast 

5.1 PULL mode: case 1 

On reception of an IGMPv3/MLDv2 request, the BTF communicates the request to the RCEF. If the type is set to 0x22 
"v3 Membership Report" in case of IGMPv3 or to 143 "Version 2 Multicast Listener Report" in case of MLDv2, the 
RCEF shall take the following actions for each Group/multicast Records present in the request: 

• If Record Type indicates ALLOW_NEW_SOURCE with INCLUDE filter mode or 
CHANGE_TO_EXCLUDE_MODE with no "Source address" fields, the RCEF shall check for each multicast 
address/source address pair if it corresponds to an existing policy rule. If not, the RCEF shall ignore the 
request for that pair. If this is the case, the RCEF shall consider that the UE wants to join the corresponding 
multicast flow and shall send a CC-Request applying the mapping defined in clause 6.1 for IGMPv3/MLDv2. 

• If Record Type indicates BLOCK_OLD_SOURCE or CHANGE_TO_INCLUDE_MODE with an empty 
source list, the RCEF shall consider that the UE wants to leave the corresponding multicast flow and shall send 
a CC-Request applying the mapping defined in clause 6.1 for IGMPv3/MLDv2. 

On reception of an IGMPv2 request, the BTF communicates the request to the RCEF. 

If the type is set to 0x16 "v2 Membership Report", the RCEF shall consider that the UE wants to join the corresponding 
multicast flow and shall take the following actions: 

• If the multicast address indicated in the Group Address parameter corresponds to an existing policy rule, the 
RCEF shall consider that the UE wants to join the corresponding multicast flow and shall send a CC-Request 
applying the mapping defined in clause 6.1 for IGMPv2. 

• If not, the RCEF shall ignore the request for that pair. 

If the type is set to 0x17 "Leave Group", the RCEF shall consider that the UE wants to leave the corresponding 
multicast flow and shall send a CC-Request applying the mapping defined in clause 6.1 for IGMPv2. 

On receipt of a CC-Answer, the RCEF shall behave as defined in TS 183 060 [1]. 

For each Policy-Rule-Install AVP that corresponds to a previously reported Policy-Update-Request in the CC-Request, 
the RCEF shall update the Max-Requested-Bandwidth-DL for the corresponding policy based on the value received 
from the A-RACF. If the value is set to zero, the BTF shall not forward the corresponding multicast flow. 

5.2 PULL mode: case 2 

On reception of an IGMPv3/MLDv2 request, the BTF communicates the request to the RCEF. If the type is set to 0x22 
"v3 Membership Report" in case of IGMPv3 or to 143 "Version 2 Multicast Listener Report" in case of MLDv2, the 
RCEF shall take the following actions for each Group/multicast Records present in the request: 

• If Record Type indicates ALLOW_NEW_SOURCE with INCLUDE filter mode or 
CHANGE_TO_EXCLUDE_MODE with no "Source address" fields, the RCEF shall check for each multicast 
address/source address pair if the corresponding multicast flow is already received. If it is the case, the RCEF 
shall ignore the request for that pair. If not, the RCEF shall send a CC-Request applying the mapping defined 
in clause 6.2 for IGMPv3/MLDv2. 

• If Record Type indicates BLOCK_OLD_SOURCE or CHANGE_TO_INCLUDE_MODE with an empty 
source list, the RCEF shall check if other UE are still requesting the corresponding multicast flow. If not, the 
RCEF may send a CC-Request applying the mapping defined in clause 6.2 for IGMPv3/MLDv2. 

NOTE: The way the transport functions know that a channel is not required by any other UEs is based on 

Membership Query mechanisms as defined in RFC 3376 [2] (IGMPv3) and RFC 2236 [3] (IGMPv2) and 
based on Membership Listener query mechanisms as defined in RFC 3810 [4] (MLDv2). 

On reception of an IGMPv2 request, BTF communicates the request to the RCEF. 
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If the type is set to 0x16 "v2 Membership Report", the RCEF shall check if the requested multicast address indicated in 
the Group Address parameter is already received. If it is the case, the RCEF shall ignore the request. If not, the RCEF 
shall send a CC-Request applying the mapping defined in clause 6.2 for IGMPv2. 

If the type is set to 0x17 "Leave Group", the RCEF shall consider that the UE wants to leave the corresponding 
multicast flow and shall check if other UEs are still requesting the corresponding multicast flow. If not, the RCEF may 
send a CC-Request applying the mapping defined in clause 6.2 for IGMPv2. 

On receipt of a CC- Answer, the RCEF shall behave as defined in TS 183 060 Rel-2 [1]. 

For each Policy-Rule-Install AVP that corresponds to a previously reported Flow-Description, the RCEF shall create 
the corresponding policy. The transport function shall forward the corresponding multicast flow applying QoS 
parameters defined in the Policy-Rule-Install AVP. For any previously reported Flow-Description that does not receive 
any corresponding Policy-Rule-Install AVP, the BTF shall not forward the corresponding multicast flow. 



Multicast to Re parameters mapping 



6.1 



PULL mode: case 1 



When the RCEF sends a CCR for PULL mode case 1, it shall use the mapping defined in table 6.1.1 for 
IGMPv3/MLDv2 request. 

Table 6.1.1 : Rules for derivation of CCR AVPs from IGMPv3/MLDv2 requests for PULL mode case 1 



CCR AVPs 


Derivation from IGMPv3/MLDv2 Parameters 


CC-Request-Type 


It shall be set to UPDATE REQUEST. 


Event-Trigger 


It shall be set to RESOURCES MODIFICATION. 


Policy-Update-Request 


For each multicast/source address: 

• Policy-rule-Name shall be set to the corresponding policy rule name for that pair. 

• Policy_rule_status shall be set to ACTIVE. 

• if Record Type indicates ALLOW NEW SOURCE with INCLUDE filter mode or 
CHANGE_TO_EXCLUDE_MODE with no "Source address" fields: 

o Max-Requested-Bandwidth-UL shall be set to zero. 

o Max-Requested-Bandwidth-DL shall be set to FFFFFFFF. 

• if Record Type indicates BLOCK OLD SOURCE or 
CHANGE_TO_INCLUDE_MODE with an empty source list: 

o Max-Requested-Bandwidth-UL shall be set to zero. 
o Max-Requested-Bandwidth-DL shall be set to zero. 



When the RCEF sends a CCR for PULL mode case 1, it shall use the mapping defined in table 6.1.2 for IGMPv2 
request. 

Table 6.1 .2: Rules for derivation of CCR AVPs from IGMPv2 requests for PULL mode case 1 



CCR AVPs 


Derivation from IGMPv2 Parameters 


CC-Request-Type 


It shall be set to UPDATE REQUEST. 


Event-Trigger 


It shall be set to RESOURCES MODIFICATION. 


Policy-Update-Request 


• Policy-rule-Name shall be set to the corresponding policy rule name for that group 
address indicated in the request. 

• Policy_rule_status shall be set to ACTIVE. 

• If the type is set to 0x1 6 "v2 Membership Report": 

o Max-Requested-Bandwidth-UL shall be set to zero. 

o Max-Requested-Bandwidth-DL shall be set to FFFFFFFF. 

• If the type is set to 0x1 7 "Leave Group": 

o Max-Requested-Bandwidth-UL shall be set to zero. 
o Max-Requested-Bandwidth-DL shall be set to zero. 
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6.2 



PULL mode: case 2 



When the RCEF sends a CCR for PULL mode case 2, it shall use the mapping defined in table 6.2.1 for 
!GMPv3/MLDv2 request. 

Table 6.2.1 : Rules for derivation of CCR AVPs from IGMPv3/MLDv2 requests for PULL mode case 2 



CCR AVPs 


Derivation from IGMPv3/MLDv2 Parameters 


CC-Request-Type 


It shall be set to UPDATE REQUEST. 


Framed-IP address 


It shall set to termination point IP address. 


Physical-Access-ld 


It shall not be present. 


Logical-Access-Id 


It shall not be present. 


User-Name 


It shall not be present. 


Called-station-ID 


It shall not be present. 


Event-Trigger 


It shall be set to RESOURCES MODIFICATION. 


Policy-rule-Report 


If the flow is already received, for each multicast/source address: 

• Policy-rule-Name shall be set to the corresponding policy rule name for that pair. 

• If Record Type indicates BLOCK_OLD_SOURCE or 

CHANGE TO INCLUDE MODE with an empty source list, Policy-Rule-status shall 
be set to INACTIVE. 


Flow-Description 


If the flow is not already received, for each multicast/source address: 

• Direction shall be set to "in". 

• Destination address shall be set to the "multicast address". 

• Source address shall be set to the Source address if present. 

• Source and Destination port shall not be supplied. 



When the RCEF sends a CCR for PULL mode case 2, it shall use the mapping defined in table 6.2.2 for IGMPv2 
request. 

Table 6.2.2: Rules for derivation of CCR AVPs from IGMPv2 requests for PULL mode case 2 



CCR AVPs 


Derivation from IGMPv2 Parameters 


CC-Request-Type 


It shall be set to UPDATE REQUEST. 


Event-Trigger 


It shall be set to RESOURCES MODIFICATION. 


Policy-rule-Report 


If the flow is already received: 

• Policy-rule-Name shall be set to the corresponding policy rule name for the 
Group Address indicated in the request. 

• If the type is set to 0x17 "Leave Group" Policy-Rule-status shall be set to 

INACTIVE. 


Flow-Description 


If the flow is not already received: 

• Direction shall be set to "in". 

• Destination address shall be set to the Group Address parameter. 

• Source address shall not be supplied. 

• Source and Destination port shall not be supplied. 
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